Computer 1998

Guest Editor's Introduction

COMPUTER 0018-9162/98/$10.00 © 1998 IEEE
Vol. 31, No. 6: JUNE 1998, pp. 44-45

Contact Voas at jmvoas@rstcorp.com.

The Challenges of Using COTS Software in Component-Based Development

Jeffrey M. Voas Reliable Software Technologies Corp.
Developers are using an increasing amount of COTS software in their projects because of the potential cost and time savings. However, faulty COTS software could cause their projects to fail. They thus need ways to minimize this risk.

We are gradually drifting toward the promise of widespread reuse, in which we can derive virtually any new system from existing code. As a result, an increasing number of organizations are using software not just as all-inclusive applications, as in the past, but also as component parts of larger applications. In this new role, acquired software must integrate with other software functionality.
This move toward reuse has become so widespread that it has even changed our industry's vocabulary. For example, software that we acquire elsewhere is described with such terms as commercial-off-the-shelf (COTS) or third-party software, commercially available software (CAS), and nondevelopmental item (NDI). When used as parts of systems, they are called components, componentware, and so on. And the systems themselves are known as component-based software or systems of systems.
There are good reasons why the industry is moving toward large-scale reuse, including savings in time and money. The cost to design and develop a new system from scratch is significant. Even the best programmers churn out only 10 lines of documented, validated code per day. This has made custom software development very expensive, particularly for systems like cellular phones, which now contain about 300,000 lines of code. If, for example, 100,000 lines of code could be acquired elsewhere, 10,000 programmer-days of effort could be saved.
Embedding large-grained software components into multiple applications also lets you spread these components' development costs across each application. This lets a wider variety of software systems enter the market at lower costs.
So, instead of building systems only from + and operators, we are now building systems from operating-system calls and language-specific development kits (such as JDK1.2) that contain standard software libraries. We are moving toward a software design paradigm where many of the software functions that we need already exist. The developer's task then is to accurately select appropriate library functions and integrate them into a system.

COMPONENT-BASED PROBLEMS

In some ways, the future of software development seems analogous to putting together a jigsaw puzzle. With jigsaw puzzles, though, you can determine that two puzzle pieces belong together simply by seeing if they fit. In component-based software engineering, on the other hand, components may integrate perfectly during development but not behave perfectly at runtime.
The goal, therefore, is to predict such problems before embedding components into a system. This would let us use components that will work safely, securely, and reliably in the systems we build.
So while we already have process models for developing software from requirements, such as the Capability Maturity Model, we now also need models for acquiring software that will work properly in our environments.
The problem is that COTS software is almost always delivered in a black box with restrictions that keep us from looking inside. Therefore, most forms of software analysis that would help you decide if the software is going to perform safely, securely, and reliably are not available.
You are thus at the mercy of the software vendor in many ways. And if your system fails because of faulty COTS components, your customers will blame you. Your reputation is at stake. This problem is particularly critical because reusable software libraries are getting bigger by the day.
This issue of Computer has four articles devoted to these and other concerns associated with the quality of acquired software:

Two articles address security concerns. One recommends risk management techniques. The other demonstrates that using various security mechanisms found in operating systems rated at Level B (the next-to-highest level of security) by the US Department of Defense's Orange Book can serve as a generic platform on which to develop secure COTS-based applications. (The Orange Book consists of standards for secure computing architectures.)
One article looks at ways to certify COTS components by assessing the potential harm they could cause a system. This methodology could let software engineers take defensive measures before adopting defective components and could help system integrators determine when to return software or avoid buying defective components in the first place.
In an interview, Professor John McDermid from the University of York in the UK discusses the practicality of using COTS software in safety-critical software systems.

CONCLUSION

Component-based software development offers engineers a number of benefits for a variety of projects. Because of this, software engineers are beginning to use the technique and want to expand the practice.
However, to achieve the goal of widespread component-based engineering, we must overcome challenges related to safety, reliability, and security. If we cannot adequately address these problems, this goal may remain unmet.

Jeffrey M. Voas is cofounder of and chief scientist at Reliable Software Technologies Corp. He is also currently the principal investigator on research initiatives for DARPA and the US National Institute of Standards and Technology. His research interests include information security metrics, software dependability metrics, and information warfare tactics. Voas received a PhD in computer science from the College of William and Mary. He is a member of the IEEE and the IEEE Computer Society.